Угнать за 
5 миллисекунд: 


как мы делали транспорт для 
торговых ядер Московской биржи 


Николай Карлов и Олег Уткин 
++ 


(HL) ноћ. сас” 


Кто мы? 


Отдел архитектуры систем хранения данных Mail.Ru 


Делаем пилоты и прототипы систем с нетривиальными требованиями 


Олег Уткин — разработчик 


Николай Карлов — главный архитектор 


(ғ) HighLoad” 


О чем будем говорить? 


В прошлом году Московская биржа обратилась к нам с задачей разделения 
торговых ядер 


Мы сделали совместный пилот системы доставки торговых данных 


... И ОН ОКазался успешным 


Расскажем об этом опыте, архитектуре и выученных уроках 


i) HighLoad” 


Что такое ‘разделить ядра"? 


Это дать возможность вынесения торгов на отдельные торговые ядра: 


а. По инструменту 
о. По ценной бумаге 


с. По какой-либо еще логике 


Пример: сделать листинг очень крупной компании на отдельном ядре 


i) HighLoad” 


Почему зто важно? 
е Горизонтальное масштабирование 


(сейчас Биржа умеет горизонтально масштабировать только чтение) 


e Минимизация рисков при листинге 


(ғ) HighLoad” 


Какие главные требования? 


e Клиенты не должны заметить разделения 
• Все должно очень быстро и надежно работать 


e А еще должно масштабироваться как на чтение, так и на запись 


i) HighLoad” 


Как работает биржа 


1: 
ааа 
ШЕШЕ! Заявка (ордер): 


J а “Хочу купить $10000 за рубли" 


Торгобо-2- 


тастер | тин 
а! 


į 


Попадает B биржевой стакан 


(ғ) Най ога” 


Как работает биржа 


8B 2 
ABB 
0] Встречается с другой заявкой 


а В результате формируется сделка 
4 


заявка частично или ПОЛНОСТЬЮ 
удовлетворяется 


Тор гово. 


мастер | "уре 
Е} 


BED 
в 


.. или через некоторое время снимается 


i) HighLoad ” 


Как работает биржа 


DDG vats наи! 
ПОН НИ ЈЕ 


.Торгобо-2- 
здро 
а 


2 


мастер 


МАСТЬ 


6) (Е) 


„Тор гобео-2- „ ТОР гово-г. 


ре зро 


E |E 


реплика реплика 


(+) Нај оаа” 


Как работает биржа 


ВАДА =. Е 
т \ 
да (Е) да „еј gamgna ` 


„ Тор гово 2- „ Тор гово-г- 
заро 
В 


į 


сте» 


В ядре есть два глобальных счетчика 


1. Кес (гесогд питбег) 
, Торгобо-2- 


здро Увеличивается при создании заявки 
Е) 

ааа 

а 


2. Seq (sequence number) 


Увеличивается при обновлении 
любой заявки 


i) HighLoad ” 


В любой заявке есть зти два поля 


Структура заявки (-600В) 


FirmID идентификатор Обновления происходят по Огдепо 
фирмы 

Вес номер заявки 

Seq сквозивиномер Запросы без фильтров по (гес, ѕеа) 
апдеитов 

Огдепо ИД заявки 
прочие : 
мотаданнЕја Запросы с фильтрами по (Ғігтір, гес, seq) 


i) HighLoad ” 


А как клиенты читают данные? 


= Свежие: 
Дай мне самые свежие заявки без пропусков 


e Новые 


е Недавно изменившиеся 


„ Тор гобо-2- 


i) HighLoad ” 


А как клиенты читают данные? 


G Свежие: 
Дай мне самые свежие заявки без пропусков 


e Новые 


Я знаю о существовании заявок с номером гес 
е Недавно изменившиеся 


“Тор гобо-ғ- 
здро 
Е} 


Е 


4% (Вес, селу | 


ДА 


И я знаю, что в бирже был апдейт зед 


i) HighLoad” 


А как клиенты читают данные? 


Дай мне самые свежие заявки без пропусков 


Клиент получает список 
заявок 


Пара (гес, seq) из последней 
заявки используется для 
следующего запроса 


„Тор гово. 
зро 
а 


С) „вес sen 
ве ъв 
ее |ЕЈ 


(гес, веа)- continuation token 


i) HighLoad ” 


Что мы поняли? 


е Клиенты получают данные поллингом 


е Необходимо отдавать самые свежие (созданные или изменившиеся) 
заявки без пропусков 


• ЕСТЬ запросы на чтение и запись по вторичным ключам 


i) HighLoad” 


А что с насчет производительности? 


конечное 
состояние 
ордеров 


события об 
ордерах 


ШЕ — Черный | 
Пее ящик 
Торговое — ОЕ 


ядро ТР5: до 200 000 


Отставание: 
р99: 5 тѕ 
ауд: 1 ms и | 
грѕ: до 200 000 (НО) HighLoad 


Почему не совсем очередь 


е При апдейте ядро отдает только изменившиеся поля 


А клиенты хотят сущности целиком 


е Если клиент отстал, то он не хочет получать все состояния сущностей 


Клиент хочет только последнее состояние 


(н) Нај оаа” 


Сводим воедино требования к архитектуре 


- Удельная производительность > 200 000 TPS на 1 узел 

- Отставание от источника p99 < 5мс, а среднее — 1п5 

- Клиент не должен знать о разделении 

- Должен гарантироваться порядок данных 

- Гарантия получения самых свежих данных без пропусков 


- Одинаково хорошо отдавать как горячие (в пределах 
минуты), так и холодные (от минуты до дня) 


i) HighLoad ” 


И тут мы понимаем, 


что это должна быть одновременно: 


ө база данных, 
ө очередь с индексами 
е кэш с вторичными индексами 


А еше: 


сгарантиями сохранности данных 
чрезвычайно быстрая 

с гарантиями latency 
распределенная 


МАЛАЯ ДОМАШНЯЯ ЭНИИКЛОПЕДИЯ 


СДЕЛАЙ 
САМ 


ШАМПАНСКОЕ 
СЫР И ШПРОТЕ 
ДРОЖЖИ 

И МАЙОНЕЗ 
ПИВО 

И МАРМЕЛАД 
МОРОЖЕНОЕ 
СГУЩЕННОЕ 
молоко 


БАЗА ДАННЫХ 
ОЧЕРЕДЬ 


КЕШ С ВТОРИЧНЫМИ 
ИНДЕКСАМИ 3 


Gi) HighLoad” 


Появилась гипотеза, что Тагапіоо! может 
подойти для этой задачи 


Тоже однопоточный и in-memory, как и ядро биржи =) 

Написан на Си 

Имеет асинхронный сетевой протокол с мультиплексированием 
Фактически это сервер приложений с кооперативной многозадачностью 


Есть примитивы хранения и доступа к данным 
о Таблицы 
о Вторичные и составные ключи 


Есть хранение данных на диске и восстановление 
Есть репликация и шардинг 
И главное: это фреймворк для создания СУБД 


i) HighLoad” 


Счетчик целесообразности выбора 
технологии 


Технология е Технологиа 
подходит е не подходит 


(н) Нај оаа” 


Структура данньх 


СИГЕ 
ключ пагинации 
СИТНИ 


i) HighLoad ” 


Сводим воедино требования к архитектуре 


- Удельная производительность > 200 000 ТР$ на 1 узел 
- Отставание от источника p99 < Бмс, а среднее — 1п5 

- Клиент не должен знать о разделении 

- Должен гарантироваться порядок данных 


- Гарантия получения самых свежих данных без 
пропусков 


- Одинаково хорошо отдавать как горячие (в пределах 
минуты), так и холодные (от минуты до дня) 


i) HighLoad ” 


Составной 
индекс 


пей! 


пе!а2 


(ғ) Нај оаа” 


Составной 
индекс 


(2, 3) 


пей! 


пе!а2 


(ғ) Ноћ. ога” 


Составной 
индекс 


(2, 3) 


Поиск первой записи – O(logN) 


пей! 


пе!а2 


В+гее 


(древесный индекс с 
прошитыми листами) 


i) HighLoad ” 


Составной 
индекс 


(2, 3) 


пей! 


пе!а2 


Итерирование по свазному 
списку О(1) 


Очень зффективно 


i) HighLoad ” 


Составнои 


И нде КС 5ед Нес 


(ғ) ноћ ога” 


Составной 
Индекс 
(update) 


Seq Rec 


Update 


Свежие данные всегда в конце Обновленный 
индекса ордер 


i) HighLoad” 


Составнои 
Индекс 
(insert) 


Принудительно устанавливаем Новъй ордер 
ордеру геа = тах server req 


Свежие данные всегда в конце 
индекса! 


(ғ) Най ога” 


Сова пока побеждает 


(ғ) HighLoad” 


Верхнеуровневая архитектура 


конечное 
состояние 
ордеров 


события об 
ордерах 


Хранилище 


Эмулятор на базе Тагап!оо! рутера 


торгового клиента 
ядра 


i) HighLoad ” 


Верхнеуровневая архитектура 


конечное 
состояние 
ордеров 


события об 
ордерах 


Хранилище 


Эмулятор на базе Тагап!оо! рутера 


торгового клиента 
ядра 


i) HighLoad ” 


Верхнеуровневая архитектура 


конечное 
состояние 
ордеров 


события об 
ордерах 


Хранилище 


Эмулятор на базе Тагап!оо! те 


торгового клиента 
ядра 


i) HighLoad” 


Первая версия реализации 


Тагатоо! Арр 


АрруЕ чеп! GetOrders 


Торговое insert ог update order get orders after key Клиент 
ядро 


собътия іпѕегі/ирааїе order select orders 


об 
ордерах 


конечное 
состояние 
ордеров 


Space (table) 


i) HighLoad ” 


Максимальный поток транзакции 


Комментарий 


При потоке без ограничений все 
начинается с 390К, а потом идет 


деградация до 340К 


1 инстанс Тагап!оо! способен выдержать поток в 340k TPS. 


i) HighLoad ” 


Сова пока побеждает 


(ғ) HighLoad” 


Рост отставания клиентов 


latency, ms 


перестаем успевать 
SLA: 5 ms принимать свежие даннье 
ДД ---------- + #+5#6- + из торгового ядра 


| 


отставание клиентов 
нарастает 


кол-во клиентов 


i) HighLoad ” 


(ғ) Нај оаа” 


Рост отставания клиентов 


резкий рост Баден 
отставания 
клиентов 


Перегрузка сетевого потока Тагаптоо! 


сетевой 
ПОТОК 


Что происходит? 


Симптомы: 
• Перегружен сетевой поток 


Выросли ВР$ клиента 
Клиентские запросы стали очень быстро обрабатываться 


(ғ) Нај оаа 


Поток данных 


клиент читает данные 
отставание клиента 


новые данные из 
торгового ядра 


(ғ) Нај оаа” 


Поток данных 


новые данные из 


= че клиент читает данные 
торгового ядра 


(ғ) Нај оаа” 


Вьвод: 


Надо мониторить число пустых ответов 


(ғ) HighLoad ” 


Начали мониторить количество отдаваемых пустых 
ответов 


их оказалось более 80% 


Они коррелируют с остальными симптомами 


(ғ) HighLoad ” 


Вьвод: 


Надо минимизировать число пустых ответов 


(ғ) HighLoad ” 


Первая версия реализации 


Тагап!оо! App 
события 
об Арр!уЕмеп! сетОгдег5 


ордерах вставка/обновление запрос ордеров 


Торговое | « 
ордера после Кеу лиент 


ядро 
insert/update order конечное 
состояние 


ордеров 


Space (table) 
key: (seq, rec) 


i) Ноћ. ога” 


Версия с уведомлением о новых данных 
Тагапіоо! App 


АрріуЕмепі GetOrders 


вставка/обновление запрос ордеров 
события 
об ордера после Кеу 


ордерах 


Торговое 1) зе! Газ! Кеу 1) if key > 1аз! кеу 
Шеп 


TAPE | май пем дата with Клиент 
2) іпѕег/ирааїе 


timeout конечное 
состояние 
ордеров 


key: (seq, гес) 


i) HighLoad ” 


• пустых ответов почти не стало 
е на порядок снизилось количество пакетов в секунду 


е снизилась нагрузка на сетевой поток на 1590 


i) HighLoad ” 


Вывод: 


Число отдаваемых данных – важная метрика 
Хотим ее контролировать 


И измерять! 


(ғ) HighLoad” 


начинаем мерить размеры отдаваемых ответов 


Распределение размера ответов 
0.8 


13:17:00 13:17:31 3:18:00 13:18:30 13190 


Размер ответа 


0 5200 10,000 14,202 


Распределение размера ответов 


Количество 


0.8 


0.6 


\ вправо 
0.4 


% Чтобы клиенты забирали 
больше записей за 1 запрос 
0.2 


0.0 


5 10 


Размер ответа 


Хотим сдвинуть распределение 


(ғ) ноћ! оаа” 


Версия с уведомлением о новых данных 
Тагапіоо! App 


АрріуЕмепі GetOrders 


вставка/обновление запрос ордеров 
события 
об ордера после Кеу 


ордерах 


Торговое 1) зе! Газ! Кеу 1) if key > 1аз! кеу 
Шеп 


TAPE | май пем дата with Клиент 
2) іпѕег/ирааїе 


timeout конечное 
состояние 
ордеров 


key: (seq, гес) 


i) HighLoad ” 


Версия со sleep 


события 
об 


Торговое Ордерах 


М - количество 
отдаваемых 
записей 


Тагатоо! App 


АрріуЕмепі GetOrders 
вставка/обновление запрос ордеров 


ордера после Кеу 


іпѕегі/ирааїе order 
if selected < М then 
sleep and try again 


Space (table) конечное 
состояние 


ордеров 


Клиент 


(нш) Нај ога” 


Бьло Стало 


+inf - - г -- -- за 
_— a | 22 жш | e | енти 
ос јан | СС ани | — 7 
9 | | | 1 | | | 3 | 5 1 4 
8 | 
7 | | 
6 ! | 
+ — = — == | 
5 — = — == | 
3 КЕСИ (ни «инв | |өнеез Фе 0 | 


=» __ < нәнә шн. < «нн ју __) | | и = и вена 1 = 
13:17:00 13:17:30 151800 13:18:30 13:19:00 13:19:30 13:20:00 13:20:30 13:21:00 1321: :30 


ооо O O 
0 5200 10.000 14202 


Максимальнои поток чтения с записью 


Кол-во CPU, % БЕСІ ms 
клиентов Размер 
без пачки 
основной | сетевой 
фильтров 


i) HighLoad ” 


Сова снова ведет 


(ғ) ноћ ога” 


Сводим воедино требования к архитектуре 


- Удельная производительность > 200 000 TPS на 1 узел 

- Отставание от источника p99 < 5мс, а среднее — 1т5 

- Клиент не должен знать о разделении 

- Должен гарантироваться порядок данных 

- Гарантия получения самых свежих данных без пропусков 


- Одинаково хорошо отдавать как горячие (в пределах 
минуты), так и холодные (от минуты до дня) 


i) HighLoad ” 


Ключ запроса для монолита 


дай ордера новее 
(зеа, гес) 


Торговое 


ядро 


i) HighLoad ” 


А если торговых ядер несколько? 


Торговое 2 
адро 
ЕА 
Торговое 
ядро Теперь нет сквозных единых (гес, seq) 


сно Най ога” 


Что делать? 


а) Ввести распределенные суррогатные геа, вес 
+ Не надо менять протокол 
- Либо это точка отказа 
- Либо нет согласованности 
- А если есть согласованность, то все медленно 


b) Что-то придумать 


Мы выбрали вариант b) – векторные часы 


(ғ) HighLoad” 


Распределенный ключ запроса 


дай ордера новее 


1(зедА, recA), (зедВ, гесВ)} 


в качестве ключа запроса используются векторные часы: 
{(seqA, recA), (зедВ, гесВ)) 


Минимальное изменение протокола, согласованнность А 2 
(НЕ) HighLoad 


Клиенты 


Реплика 


Источники 


Виды клиентов 


i) HighLoad ” 


Клиенты 


Реплика 


Источники 


(НЕ) HighLoad” 


Клиенты 


Реплика 


Источники 


(НЕ) най ога” 


Клиенты 


Реплика 


Источники 


(НЕ) HighLoad” 


Кластер Stateless- 


Источники Тарантулов роутеры ! Клиенты 


Реплика без 
индексов по 
фильтрам 


(НЕ) HighLoad” 


Тест с репликацией 


Запись, 
Клиенты TPS 
[omon ааа [pom o ЕСЕСІН 


Master (читают клиенть с фильтрацией и минимальной задержкой) 


Replica (читают клиенты без фильтрации) 


Сводим воедино требования к архитектуре 


- [ОК] Удельная производительность > 200 000 TPS на 1 узел 
- Отставание от источника p99 < 5мс, а среднее — 1т5 

- [ОК] Клиент не должен знать о разделении 

- [ОК] Должен гарантироваться порядок данных 


- [ОК] Гарантия получения самых свежих данных без 
пропусков 


- [ОК] Одинаково хорошо отдавать как горячие (в пределах 
минуты), так и холодные (от минуты до дня) 


i) HighLoad ” 


Тело ответа 


гедиез! гесемей 15 
гедиез! десодей 15 
сіогаде диегес 15 


баісһ аз! 5еа 
раїсһ Газ! гес 


о!дез! огдег те 


гесога! 
гесога2 
гесогаз 


Трассировка (диагностика) 


курсор 

время самой старой записи в пачке 
(диагностика) 

пачка ордеров 


i) HighLoad” 


Процесс запроса 


Тагап!оо! Клиент 


запрос 


рые декодинг заголовка с курсором 


анан 222 для следующего запроса 
запрос 


декодинг ордеров 


i) HighLoad” 


Эмуляторы 


конечное 
состояние 
ордеров 


события 06 | Кластер Tarantool 
ордерах 


Эмулятор | Змулатор 
t= ма 


торгового 
ядра 


i) HighLoad” 


Змулятор торгового Эмулятор клиента Приложение на 
ядра (источника) Тагап1оо! 


генерация ордеров подсчет времени логика работы с 


путешествия ордеров анными 
имитация всплесков у PAER A 


сбор трейсов из сбор метрик СРО 
тарантула 


Rate limiter 
сбор метрик 
подсчет RPS чтения хранилища, в т.ч. 


Prometheus exporter insert/s, update/s, 
АЕ една select/s, table size 


пачки 


подсчет КР$ записи 


Prometheus exporter 


Prometheus exporter 


i) HighLoad ” 


Змуляторь 


Бьло 


Змулятор 
торгового 
ядра 


Эмулятор 
клиента 


Стало 


Демон эмулятора 


Источник 


Клиент 


i) HighLoad ” 


Автоматизация нагрузочного тестирования 


Демон змулятора 


СЕЕ 


Источник Клиент 
ПрофилБ 
тестирования и —>| Апсіріе 
конфигурация Prometheus 
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Сводим воедино требования к архитектуре 


- [ОК] Удельная производительность > 200 000 TPS на 1 узел 
- [ОК] Отставание от источника p99 < Бмс, а среднее — 1п5 

- [ОК] Клиент не должен знать о разделении 

- [ОК] Должен гарантироваться порядок данных 


- [ОК] Гарантия получения самых свежих данных без 
пропусков 


- [ОК] Одинаково хорошо отдавать как горячие (в пределах 
минуты), так и холодные (от минуты до дня) 
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В итоге 


- Пропилотирована архитектура распределенной системы доставки 
торговой информации с использованием Тагатоо! 


- Пилот признан успешным 


- В будущем планируется развитие 


(ғ) HighLoad ” 


Сова победила 


(ғ) ноћ ога” 


Выводы 


- Есть проблема - надо научиться измерять 

- Строить сложную систему итеративно от самого простого 

- Измерять не только бизнес-метрики, но и технические метрики (ОС, 
железо) 


- Изучать особенности алгоритмов обработки данных и структур данных 
инструментов 


- Иногда полезно замедлять клиентов 
- Батчить запросы, экономя CPU и сеть (в особенности пакеты) 


- Использовать инструменты и технологии по назначению 


- Автоматизировать тесты и забирать дамп из Prometheus ;) (НЕ HighLoad” 


Спасибо за внимание! 


Вопросьг? 
Будем на связи: 


пкоау.капом(Фсогр.тай.ги 
o.utkin@corp.mail.ru 


При подготовке зтого прототипа ни одна сова не пострадала! 
(Но HighLoad ” 


